I managed to miss a few of the last week journals so I seek to catch up in this longer journal post.

In the lead up to the final exhibition, as a team we managed to meet up on campus a few times. This was excellent as we hadn't been able to previously and as each of us were working on the same Sassmobile, it was imperative that we caught up.

As we quickly discovered the project was more complex than expected and bringing together all of the different parts of the bot would be tricky.

Problems

The first problem we encountered was being able to connect the ESP32 to the arduino Uno. As both systems need to talk together in order for the bot to function it would serve as a challenge. The best way for this to happen would be to connect the RX/TX of the ESP32 to that of the Arduino Uno. Sadly they were already in use from the speaker. Luckily we could use pin 16 and 17 to the same purpose.

An individual problem I had was getting the robot to follow your face. It was a cool feature, and one that I wanted to get working desparately, however not completely core to the project. The problem was that the robot didn't move fast enough to follow a face.

We then tweaked with the code so that the bot would turn when being looked at. A few of the problems we suspected were the serial using up too much time, so we deleted any serial code. We also tried using a case switch statement to clean the code up. Sadly I didn't capture any footage of the bot moving when being looked at as the camera was being used for facial recognition.

switch (BluetoothData) {

  

  case 49:

    irsend.sendNEC(0x4FB58A7, 32);

    break;

  case 50:

    irsend.sendNEC(0x4FBF20D, 32);

    break;

  case 51:

    irsend.sendNEC(0x4FBC23D, 32);

    break;

  case 52:

    irsend.sendNEC(0x4FB42BD, 32);

    break; 

  default:

    

    break;

}

As shown in the code there are 5 different cases. The data received from the Arduino phone app sends through the Bluetooth serial either 49,50,51,52 or 53. I implemented the robot movement codes for each case. In case 49, the Face Recognition app detects a face in the left side of the screen, meaning the robot needs to turn left in order to center up the bot with their face. For the bot to turn, it sends an IR code with that command from the ESP32 to the vacuum, causing it to turn.

In terms of the design of the bot, we decided to custom paint a cardboard box, that Anshuman glued the various lighting strips to. We finished up with this.

Due to health reasons, we couldn't meet up with Ben til the exhibit day, so Anshuman and I met up again without him. We continued to work on the bot, when we encountered issues with sound. Low and behold, Ben was our sound engineer. Anshuman and I then tried to understand his code, and seek to solve the problem. We were however unsuccessful. We later discovered the problem was most likely a power issue. As the one Arduino uno powered all the lights (over 40 LED) plus the potentiometer, touch sensor and sound, it simply couldn't handle all of the load. We were then unsuccessful in our attempts at powering the setup separately, as we didn't think this was the problem.

The Exhibition

On Exhibition day, we all came into uni. I brought in my TV so that we could demonstrate channel changes, and my ESP32 and the vacuum, and Anshuman bought in the bot. We then spent the next few hours trying to finalise everything up, however quickly encountered issues with Arduino. To our luck, they pushed an update which affected the loading of the IDE, meaning we couldn't edit our code. We were able to find a fix, which meant deleting all of the temporary storage of the IDE, including packages. For Anshuman, this wasn't a big problem as he was using the Arduino Uno however as I was using the ESP32 and had previously installed an array of libraries to run the various IR codes and Wifi codes, all of these were deleted and the bug meant I wasn't able to redownload them. All of a sudden our bot had lost half its capability.

Presenting to you the Sassmobile, simulated edition.

As we were unable to fix the power issue, we had Ben run the DF robot sound separately and on queue, Anshuman was our model man who sat watching the TV, and controlling the lighting on the bot. I was able to move the robot around using the remote control. Sadly we couldn't get it all together in time however it has been a unique learning experience. Perhaps with more time, access to 3d printing resources to enable a more solid build, and better understanding of our problems we could have built a better final product. I am still proud of the boys. #teambatsqwad it has been an honour.

Here is our team video of the exhibit on the night.

Building and Materials

After collecting resources from the workshop room, including the wooden hand, wires to move it, servos and pulleys I started building the final product. Working off the feedback from the prototype the goal is to make a more sturdy hand where the fingers can move freely and be positioned in any way I wish. The wooden hand has stiffer joints which enable the fingers to stay in almost any position which should come in handy for that. With all the wires attached to the fingers however, it is clear that they will not pull themselves back up like the elasticity that was in the cardboard hands so wires will also be needed at the back to pull the fingers back up. Additionally wires will be attached to the wrist and back to the servos to move the hand, and need space to rotate and move around in order to properly pull the strings.

As you can see below, I made a huge mess with all the materials and building, where most of which was done by trying to solve a problem using trial and error. Building using odds and ends I found at home, I used a plastic container for the arm which turned out to be quite sturdy, but needed to drill holes into the top and sides to attach the servos in so they could rotate it. A servo was attached to the wrist and the hand was pulled off the of the arm it was attached to in order to attach the wrist servo to the base of the hand.

Putting it together

The foam base from the prototype worked very well and the servo was placed inside the plastic container for the next stage where all servos were in place. Another box was used as the container for all the wires and Arduino back end to put it all together and out of sight. With the physical components set up, the next stage was to connect all the wires on the hand to the servos, code the Arduino components then attach it all to the box and battery to make sure the hand stays where it is while getting powered to move and perform gestures.

With everything in place the wires were loose to not stretch themselves out of place before the exhibition while getting all other parts in place. Glue and lots of tape was used to keep the hand in place, all weight resting on the arm servo as the hand will have to move independently to wave, thus not resting its weight on the base of the arm at all. The two distance sensors were placed outside the box facing forwards, offering a simple method to see from which direction people would approach the concept, then the arm would rotate to face the side from which they approach. This was done easily by comparing the distances at each and then using the distance of the side which was closer, and then the action relevant to the distance detected would be performed.

After all the time and effort payed off, the final product was finished and worked decently well, however the battery runs out very quick and when I attached the hand it turned out to be very difficult for the servos in the wrist and arm to rotate. I am quite happy with the look of the final product and believe that it works quite well for the intended concept, and if it wasn't too heavy it could have been a successful design.

Server issues

This week the team and I needed to make sure that the server was up and running before the exhibition. Sigurd and Thomas had already made the sever work for their prototypes but it was important that it worked for all of our team members. However, as we tried to send the colour values over the server it became apparent that something was wrong and it just refused to cooperate with us. After several hours of trying to make it work we simply had to give up since other tasks were more pressing

Later this week while Tuva was trying to make it work it suddenly just did. What was initially wrong and how we fixed it some a bit of a mystery but thankfully we managed to make it work.

I also learned this week that Sigurd's prototype is broken, so for the exhibition we will only have 3 functioning prototypes. This shouldn't be a problem but it would have been ideally if everyones prototype could be displayed on the exhibition.

Website

This week I became mostly finished with the websites design, the only thing that remains is writing the content which I find to be the boring part of building a website. However, I must say I became very pleased with the header image I created for the website. I was inspired by the sketching tools for arduino and created it to look like a breadboard etc.

In the end, I though this project was fun and I learned a lot about the theme and creating prototypes using Arduino.

Additional feature

This week I added the final interaction to the prototype. Based on the feedback I had gotten on the prototype demonstration I decided to add a way for the users to delete the message instead of sending it, if that is something they wish. During the prototype demo I also got confirmed that the throwing interaction was an appropriate metaphor, based on this I decided that the delete metaphor should be the opposite, namely drop the ball instead of throwing it upwards. This, however, turned a little more difficult than anticipated since it required the accelerometer installed to know the difference between a throw and a drop. By studying the output values registered when performing these various task, it became apparent that they behaved differently from each other. The throw slowed down at the top of the throw before it falls down again, while a drop has only a quick stop of the acceleration. In the end, I managed to make it work.

Because of the time restriction and the restriction I won't be able to conduct a user testing to confirm if this last interaction is the best way to delete the message. A different metaphor might be even better than the one I have chosen but hopefully it will be easy for the user to understand and interact with.

Next week

Since the prototype is almost finished, I will start to make the website for the exhibition. I have already some ideas of the design that I want to create for the website and hopefully it will turn out as good as I have imaged. Building a website is just fun in my opinion so this is something that I look forward to.

My goal this week was to implement additional note blocks so that more than one note could be placed and played. I successfully got it all wired, and the Arduino Serial monitor is reading each note block correctly, but I am still having issues with getting Processing to consistently read the Serial. I’m not sure what the issue is, but I hope to have it resolved by the exhibit next week. I’m also a little concerned that I still haven’t started creating the form yet, but I feel that having a working prototype will be better than a good looking one.

Our team has decided to go with a similar colour scheme for all our portfolios, to create a team feel, but each designing individually. I haven’t created a website in over a year, so I don’t think my portfolio will be particularly impressive, but I hope to have it at least presentable.

My main concern this week was the feedback I received from last week’s demonstration. Many people said that my concept didn’t achieve what I said it would, namely that it doesn’t demonstrate fractions and proportionality. I was initially worried that I would have to change my concept entirely, but after speaking with Lorna, I’ve decided to simply change the scope so that it is explicitly teaching children about music and rhythm.

I haven’t made any more progress on implementing features on my prototype, because I was worried that any progress I made might have to be undone if my concept had to change. I still need to implement sound, as well as add more note block circuits and find a way to consistently register pressure, as it’s much more precise than I first realised.

Creating the video and prototype document has helped me further develop and understand my concept. In particular, I decided to have two states for the device, locked and unlocked. Because the concept focuses on using weight to understand fractions and proportionality, I thought it would be good to have a setting where users could only manipulate the weights, and the note blocks are locked in place. In the unlocked setting, users can change both note blocks and weights as they wish, to allow for more open-ended creation. I’m interested to see what feedback I get from this change, as I have only really thought of it this week, and haven’t had the time to really think about all the implications.

I’m a bit concerned that my demonstration video is quite short, however I felt that there wasn’t really anything else that needed to be added. I felt that a short, clear explanation and demonstration was better. It does make me a bit worried that my concept isn’t complex enough, if it can be explained in such a short time, and I’m concerned that it’s getting too late in the semester to make any significant changes. I will have to wait and see what feedback I get.

It was also interesting to properly see other peoples’ concepts for the first time. Some groups were almost intimidating in how much progress they had made, while others gave me more perspective on my own progress, and made me feel like I’m not as behind as I thought.

I was also able to speak to tutors in the Thursday workshop session about options for constructing the form. They assured me that a high-fidelity prototype was not necessary, and that consideration will be given to the difficulty accessing materials and tools this semester. That made me feel a lot more at ease about getting my prototype finished.

This week I worked on a system to detect which note block is placed. At first, I was advised by tutors to use a camera and make use of either Vuforia or a colour detecting program. After spending some time reading and researching various camera technologies, I was still very confused. I asked again at the workshop session, and this time I was recommended to use copper tape as a switch to create a circuit. This made much more sense to me, and I used copper tape on the bottom of the note block to create a connection between two jumper cables. I coded the connection like a button, so that it sends the note name to Serial, along with the pressure sensor reading, whenever the note block is placed.

I have since added a second button to function as the play button, so that the readings are only sent to Serial when this button is placed. I had some trouble getting all the buttons to work, particularly with getting the buttons to register being reset and ready to send the next reading. Again, I got help from tutors to use a state check, along with some tutorials online, and successfully got all buttons to work as intended.

While I have gotten the three main functions of my prototype working, they are all in their most basic form, and I still have to use the readings to actually play the correct sounds. This will have to be mocked for next week’s demonstration. I also haven’t given much thought yet to how I will create the form of the prototype, as I’m still very much focused on the functionality. I’m also a little worried about how I will actually create the form, as I don’t have a whole lot of access to materials.

I spent time this week, as well as previously during semester break, working on getting the pressure sensor working with the Arduino. I used tutorials online, and managed to get the pressure sensor to send readings to the Serial monitor. At this stage, it just prints readings every second, so I will need to work on getting it to send readings only when needed.

I have struggled a lot with motivation lately, and am still not fully adjusted to online learning. I’m worried that, given I have only just started working on my prototype, I won’t be able to finish it to a sufficient standard. Just the work I have done recently has revealed several smaller issues that need to be resolved, such as how precisely the pressure needs to be applied for it to be registered, and I’m only just coming to realise how much time it may take to properly implement all the features I planned. Combined with my motivation recently, I’m doubtful of my ability to complete my prototype to a standard I’m happy with.

Reflection (my submission):

After I completed making my first prototype, I recorded the different parts of the video using my phone. I asked my flatmate to be a part of it and do the actual demonstration. I thought that would be a better way to represent rather than me using my own product for demo. I also asked a few questions to the user regarding my product.

Overall I think the video was of a very good quality with both goof audio and video.

During the studio, we were meant to give detailed critique to a 3 other assigned teams. We decided to watch the videos one by one per team and read each document and give critique before moving onto the next person's video and document. I think this was a good and quick method. As we all waited for each other to complete writing our critiques, we were getting more detailed ideas and improvements for the projects we were looking at. What I had from previous courses as well was that the best way to give feedback was if I pointed at something that I didn't found the best, I suggest a better or a different way. This way, the person would be able to think about other ideas as well.

After we went through all of them, We thought it'd be best if we divided all the individual project's critiques that we all wrote and basically summarised the points. In the end, we all got to summarise 3 to 4 appraisals. This didn't take too much time as we all had written good, valid points for the appraisals.

Report Back

What have you achieved in the last week towards your prototype goals?

My theme is digital sensation and creative learning and my goal is to create a product which teaches its target audience a good habit. The good habit being disposing of any waste and garbage properly. My target audience are children going to school of age between 6 - 16 years. Since last week, I went to the workshop and clay helped me get a new Arduino as there was some problem last week with my Arduino. Once I got my new Arduino, I worked on connecting a NEOpixel ring. Once I connected it and it started working, I next connected the 2 ultrasonic sensors and made sure that those were detecting things properly.

What are the last-minute tasks you need to complete before prototype submission next Monday?

Before submission of my prototype, I need to make sure that the ultrasonic sensors and the lights work together. Basically I need the light to change whenever either one of the ultrasonic sensors are used.

To be specific, I need the colour of the neopixel ring to turn into red when the non-recyclable waste ultrasonic sensor is interacted and turn green when the recyclable waste ultrasonic sensor interacted. As I have already made sure that the colour change is slow and is done in a smooth motion, it should be easy to connect the 2 devices properly.

What are your concerns/needs in regard to getting those done?

What could be a greater concern than both the devices that I talked about in the previous question not working together? That being my greatest concern, I just have to assemble the prototype itself as well, which shouldn't take much time as I a box and a plank which I will be using to make the 'Globalzoo', the bin itself.

Prototype Development:

Other than the functionality, I have to figure a way out to show the globe itself. I can either make use of a translucent paper and cut into a circle and draw the earth itself on it or I can but a spherical glass lamp of some kind. I am not entirely sure if the cardboard box will be able to hold the weight of the lamp. But the amount of time I have left, I think for this prototype, I will just go with the first option of using the translucent paper.

The final week have come and gone, and we all made it through to the end. In the last days leading up to the exhibition, we revisited our team reflection one last time before handing it in and tested to see if our prototypes worked one last time after having merged our codebases. Finally, it worked to send messages to each other with all code merged! Although my prototype still was broken, we were able to show off our combined effort at the trade show.

As for the tradeshow, at first, we did not get many visitors, so we had an extended chat with Ben before Matt later arrived. Marie mostly held the presentations as her ball was one of the more reliable ones in terms of sending information to the others, whereas Tuva's worked half of the time and Thomas' broke midway through. Thomas was able to fix his again for the rest of the exhibition though. Later on, we had a flock of visitors who wanted to check out our concept, which was nice, and we did receive a lot of positive feedback. It was also nice to see how some of the other projects ended up and peoples' creativity in finding a way to prototype their concepts. All in all, it was a great ending to a long and exhausting semester, so I'm glad we can put that behind us and keep focusing on the thesis.

I didn't really receive any feedback on my portfolio, except from within my team. Seeing some of the other portfolios I decided that my time would be better spent working on the thesis rather than fine-tuning a few more things on the website, as it is rather good already.

Thank you to all for a good semester!

Gesture Based Research

For the gestures that I want to use in my robotic hand, first I need to make sure that none of them offend people. Therefore, to quickly gather some data I asked several people around the target market base of 18 -30 years old what gestures offended them, and in what context. Many of these gestures were deemed offensive but required more of the human body than just one hand like my robot. With a lack of body and other hand, many of these gestures are impossible or if attempted don’t look the same and aren’t offensive. For those gestures that can be done only two were an issue, with flipping the bird and using two fingers to represent ‘up yours’ were deemed offensive by some, however the context was when the gesture was directed at them by others, especially those they don’t know or when in an argument this gesture would insult them if done with intent. After asking whether these gestures done by a disembodied robotic arm would be as offensive, most participants responded with no, rather it would be humorous or novel to see, not offensive. There was nobody in my research group who would want a robot to not do these basic gestures due to a caused offense in this group.

Use of Research

Overall this showed me that it would be okay to use seemingly offensive gestures for my robot as they don’t come from a harmful place and is rather a novel method of interaction and shouldn’t offend anyone in the user group. The only potential issue is with second-hand viewers like children, however the nature of the concept doesn’t mix well with kids as the moving parts and many wires make the product fragile and susceptible to being broken, therefore in my project these gestures will be used to convey aggressive intent by the robot.

Update to Research

It is now week 13 and Lorna has just notified me that using the middle finger emoji in my branding of ‘hand signs’ for my portfolio could be unsuitable as school kids are attending the online exhibition. While the kids themselves might revel in the included ‘vulgar’ gestures, their parents would less than enthused. Rather than risk the concern, these gestures will be censored and not used in the robot, and more simple emoji notices will be used in the design (from middle finger to thumbs down on the site) in order to reduce the risk of possible offense to parents or guardians of the attending kids.

At the end of last week, I mentioned some issues I had with my prototype. Sadly, both the accelerometer and bend sensor are broken, rendering my prototype unusable. I have spent a lot of time on this subject this semester, but most of the time has been spent trying to solve technical issues, which in the end have stolen countless hours from building a prototype that we can use to gather data from. Given that I've dedicated most of my time to PhysComp, I don't really have any more time to spend to rebuild my prototype if I ever wish to finish my master thesis. It's a sad way to end the semester by having your prototype break down. Luckily I have a couple of pictures, a short video and my test results to show for. The test results are in the end why we made the prototype in the first place.

Tuesday

After Tuesday's stand-up, our team met to discuss how we should work on the team reflection. We ended up with a divide and conquer method, splitting the parts amongst ourselves. Some of us started to write a draft on the team reflection the very same day before we iterated on the text later during the week. Then we proceeded to check if our combined code base worked after everyone had updated their code. This didn't turn out as we expected, we found some new issues that hadn't been there before that didn't allow us to receive data from each other anymore. Moreover, the overall experience and functionality were rather janky and unreliable, as it jumped back and forth between the different states, seemingly at will. Thomas, Tuva and I spent many hours that day trying to figure out what the issue was but were unable to fix the issue. The reason for these issues in the first place is probably a lack of communication and planning out the system ahead of time, which likely would not have been an issue if the semester ran as normal where we could meet up and discuss things in-person. We did discuss a plan B in case we did not get it up and running again, as Thomas and I have our previous combined codebase, where sending and receiving worked on both ends and Tuva and Marie have their individual working code. However, if possible we would like to present one working codebase and functional prototype. For the rest of the week, given that Thomas and I had previously spent the most time on the combined codebase, Tuva volunteered to spend some time fixing the issue, as Thomas and I were falling a bit behind on the thesis.

Portfolio

I did spend some time finishing up my portfolio this week. I've been pushing ahead a bit to finish it ahead of time as I need to spend as much time as possible in the coming weeks on my thesis. Most of what I did on my portfolio for this week was to write down more content and make sure the website was fully responsive and accessible. Working on the portfolio took significantly longer than I expected it to, and it all feels a bit repetitive given that we are re-writing the very same things we have already written about here in the journals, the proposal and in the prototype delivery previously. Also, building the site took more time than expected as I'm not used to working without a framework. I could really see the differences in all the heavy lifting a framework does for you and the time you save as a result of this, but then again, the content is what took the most amount of time.

After Critiques

After all the responses from the critiques on the Miro board and lots of good feedback and inspiration from seeing everyone else's designs I went into the studio on Friday and picked up the new and improved wooden hand that I want to use in my final version of this concept. In the workshop I also wired the strings through the finger joints in hopes this will better pull them down and back up from behind, operating just like tendons do in our real meat hands.

Along with the hand, I got stronger and larger servo motors that should better rotate and pull the strings a full 360 degrees this time to properly operate the strings in order for the fingers to move better than in the prototype. These came along with disks on top which will hopefully be able to run the threads through on tracks in order to pull the strings which moves the fingers a larger amount.

Sadly this was all the physical work I could do this week as I was otherwise very busy with other INFS subjects and finalizing work for them. Next week I hope to further complete this final build, making the hands look better with some other design work, hooking all the strings and wires up to the servos and building a sturdy base for the whole build so it is secure and can be fitted on a desk in a easy casing with a sturdy base.

I spent most of my time last week working on the next prototype and my annotated portfolio.

Studio & Workshop

In the studio, we had our regular stand-up with this week's focus on having a one-line pitch for our concept, show what we have been working on, what our priorities are for finishing the project for the exhibition and questions regarding the portfolio. Although we have slight variations of pitching the concept and thoughts of the ideal product, given that we are still exploring different aspects, our current one-liner is "E-mories, a distraction-free physical platform to remotely share personal emotions with close friends and family". Moreover, for my progress, I showed the state of the ball, which at that point in time was the new ball with a bend sensor attached with silicone to the inside. As for priorities finishing the project, we had already fixed it so that all devices could communicate over the server, so we mostly just had to continue focusing on making sure our individual prototypes works and to conduct user testing for the last prototype.

Prototype

As for the prototype, I found a nice transparent ball at K-mart which I could use. The ball had a nice pattern to it which I believed could reflect the colours in a neat way and it also contained some glitter water inside. At first, I didn't think much of the glitter water as I mostly wanted to use the ball. However, looking back at our additional features suggested in the proposal, one of them was to add water to the E-mories device. Given that I am building this prototype to test material and how to make the device more of a personal artefact, I decided to test how adding glitter water could make for a unique look and feel and test whether it made the device feel more personal.

I drained the water from the ball and started to place the various Arduino components and sensors inside, making sure they were all fully covered in silicone to avoid any water touching the electronics. I covered all electronics I could in clear plastic wrap and black tape before I covered them in silicone, to better protect the electronics. I let the silicone dry before I carefully tried to put some water inside to see if it was still leaking. Three times I had to put more silicone in to stop the ball from leaking, which was strange as I by the end had covered the entire bottom half of the ball with silicone.

When I finally had made sure it did not leak, I tested to see if everything still worked, which it did, but the accelerometer has ever since testing it for the first time seemed quite unreliable as it seems to mix angles. As for the working parts, they can be seen in the images and video below. At this stage, everything from recording to picking a colour, sending data and getting an incoming message notification worked as intended. However, when I picked the prototype up the next day, the bend sensor values were all over the place, which made nothing work. I inspected the ball for water leakage, but there was none. I knew from when I received the bend sensor that the connection was somewhat loose which I had taped earlier to avoid these issues and later put silicone on top of to hold in place. Despite this, I seem to have some issues with the bend sensor. Having tried to fix the issue for a couple of hours, I decided to drain the ball of water in case that had any effects on it. So, I'm going to let it dry off before trying again. If not, I might have to stimulate the squeeze interaction as I would have to pull everything apart to access the bend sensor and fix it at this point, basically meaning I would have to purchase a new ball and start over from scratch.

Web Portfolio

As for the rest of the week, not counting the time I've spent working on my thesis, getting ready for the prototype demonstration there, I spent working on the portfolio. My current progress can be found here: portfolio

Most of the time I've spent working on the portfolio has gone to rewrite and condense what we have already written about in the proposal, journal and first prototype delivery. Re-writing this content feels rather repetitive and as a result, made my motivation take a hard hit. I'm still struggling with motivation in both courses as there is a lot of repetitive work and every day feels the same, not being able to have a social life for the entire semester. Still, I believe I'm on track for the exhibit and portfolio in PhysComp, while I still need to catch up on the thesis as PhysComp requires most of my time throughout each week.

Work Done

Spud

I have been working on implementing the ultrasonic sensor and the voice recognition and have met with difficulty in making them work together without confusing the Spud program. As the ultrasonic sensor and the voice recognition software are always on, I have to decide on giving one of them the priority of making an action. Otherwise, as I'm experiencing now, when Spud detects someone nearby and listens to a voice command, it does the actions one after another without stopping. Therefore, I have decided to make voice commands the priority. Also, I have to think of a way to loop the angry expression and the stop motion where Spud shakes its head as long as it is detecting that someone is at that distance. Otherwise it would be weird if Spud just goes back to a neutral position after a while even with the person still standing there not taking the hint when it is supposed to do try and make that person to go away.

On the mean time, I did testing on the interactions of Spud with participants. I tested whether the participants understood the meaning of all the different movement and how they felt for each of them. A few commented that the movement was too slow and the dancing trick looked like Spud is angry instead of being playful. In response to this, I will increase the speed and try to make Spud look a bit more silly instead of angry.

Website

I first planned how my portfolio will look like and have now completed the overall frame of the website and chose its colour scheme. I also drew some illustrations and icons of Spud so I can add them into the website.

I will complete all the functions and features of Spud as soon as possible and conduct a final user testing observation and interview while adding details and information into the website.

Feedback

On Monday we had a meeting to discuss the feedback we had received and our path going forward. Both as a team and for my individual project, we received some useful data, however, some things that were mentioned were answered in the video and document and provided little value. Most of what we received was helpful though and does correlate with the data gathered from user testing and interviews.

As for my own project, feedback and user testing data suggested that I should look into the material and also how the device could make for a more personal artefact. Other than this, most of the feedback I received only requires minor fixes in the codebase, such as not having to hold after squeezing until the audio is done playing and smoothing out the quick flash at the end of the notification cycle for a more pleasant experience.

We decided during the meeting to focus on putting all our code together into one codebase to better be able to showcase our concept on the tradeshow. We also set up another meeting for Friday to start merging the codebase. We chose to focus on merging our code before continuing to work on other features on our individual projects as more code would mean more refactoring. Given that all of us had to focus on our thesis for the coming days, this did not cause any issues for us.

Midweek

As for Tuesday and Thursday, we had our regular stand-ups. I did like that we were all going to say one positive thing given that a lot of stress with covid on top quickly makes for a negative pattern. All week up to Friday, except for Monday's meeting and classes, I had to spend working on my conference paper for my master thesis as I had mostly been focusing on PhysComp and had that due on Thursday.

Friday's Meeting

On Friday our group met at Uni to start merging our code. Whereas Thomas and I had an easy time merging our codes, Tuva and Marie had to start from scratch using a new library for their MPU6050's. Given that we had an easier time putting our code together we put in place a couple of functions so that Marie and Tuva could easily merge their code with ours without having to read through and understand it all.

Weekend

During the weekend, being inspired by Thomas' solution to create a ball from silicone, I chose to try doing the same, only instead exploring a different shape. I went to Indooroopilly, to purchase some clear silicone and then headed back home to make a mould for my shape. I decided to try to make a cube due to how it is easier than most other shapes to make and then Thomas and I would be able to test two different variations to see which one felt better. My thoughts were also that using different shapes could be a way of making the artefact more personal as people could pick their own shapes or a pair where two and two E-mories devices would have the same shape to distinguish them from others. However, after two attempts, one time with only small amounts of corn starch to retain some translucency and another time with a lot of corn starch, it still would not dry, so I ended up scratching trying to make my own cube out of silicone. My plan B would have to wait until Monday as I had previously seen some clear balls laying around at K-Mart on Toowong that I could work with.

Work Done

This week I started looking at ways to implement the ultrasonic sensor and the microphone into Spud.

I started watching videos of how to use ultrasonic sensors and tried it myself. It was quite straightforward and easy to work on. For voice recognition, I found a way of using the microphone on the laptop instead of the Arduino microphone module using C# (they used the Visual Studio IDE) from this website tutorial here. Hopefully it would not be that hard to implement these in Spud as it might be tricky to do this with two different modes, the alert and friendly mode, and having to send information from the visual studio IDE to Arduino.

I also did user testing to determine how far the distance of the person walking towards the user should be before Spud reacts. Results:

• >1.3m away from user = normal
• <1.3m away from user = Spud turns angry as a warning
• <0.8m away from user = Spud shakes its head/ waves to the person.

Work to be done

For Spud, I have to start implementing the ultrasonic sensor and the voice recognition as fast as possible. At the same time, I also have to work on my website as that might take a long time to make it nice and presentable. I'll first make the form of the website and set up the CSS and JavaScript code. Then, I will write down content about my work with Spud and decide how to display it without making it just seem like a document.

Team meeting

This week my team and started with having a meeting to go through the feedback we had gotten and discuss what the next phase of our development would be. The feedback we had received was mainly positive and gave us confident that our concept and how we displayed it in the video was good and that people thought it was exciting.

Everyone of us had asked questions in our videos in addition to a series of team questions that asked around the overall concept. For my prototype I got confirmation that the trowing metaphor was appropriate for its functionality. In addition, many expressed that a way for the users to either replay the message and/or delete was something we should include so this will be taken into further consideration.

At the team meeting we decided that we would have a physical meeting on Friday to see if we were to put the prototype together as one.

Friday Meeting

The team concluded that we would try to assemble all of the prototypes into one so that each and every ball could perform the entire interaction flow. While Thomas and Sigurd managed to put their prototypes together fairly easily, me and Tuva met with some additional issues. Firstly, we hadn't used the same libraries on our prototypes so we had to decide on which one to use. Tuva tried to install the one I used, but for some reason this didn't work and so, together with a tutor, we decided to scarp it all together. A new library that was available for both me and Tuva was found so we decided to use this one. Since most of my code had been based on the last library I had used meant that I had to rewrite most of my code. It took my a while but I managed to make it make it work finally. Secondly I was tasked with merging mine and Tuvas code. However, as we expected the accelerometer couldn't distinguish between a shake and a throw so it was decided to add a squeeze in-between to "lock" the colour and starting the throwing state of the ball. This worked perfectly and so now the interaction is as follows:

The inside of the ball looks currently as a hot mess but everything works perfectly. However, because of the new pressure sensor the schematic was even more difficult to look decent. Hopefully people can make something out of it.

Going forward

Based on the previous user testing the team also discussed some additional feature that we could add or try separately. For my part, most of my users wanted a way to delete the message instead of sending it. I was thinking of adding some code which registered when a user dropped the ball instead of throwing it upwards and that this could be a good metaphor for deleting and resetting the ball. This is however something I will have to look into closer at a later point.